uy8 


NASA Technical Memorandum 88263 


( NAS A -TM -88 26 3) AN ENGINEEBING APPBOACH TO N86-24687 

THE USE OF EXPEB1 SYSTEMS 1ECHNC10GY IN 
AVIONICS APPLICATIONS (NASA) 12 p 

HC A02/MF A0 1 CSCL 01D Onclas 

G3/05 43063 


An Engineering Approach to the Use 
of Expert Systems Technology in 
Avionics Applications 

Eugene L. Duke, Victoria A. Regenie, Marylouise Brazee, 
and Randal W. Brumbaugh 


May 1986 


NASA 

National Aeronautics and 
Space Administration 






NASA Technical Memorandum 88263 


An Engineering Approach to the Use 
of Expert Systems Technology in 
Avionics Applications 


Eugene L. Duke, Victoria A. Regenie, and Marylouise Brazee 

Ames Research Center, Dryden Flight Research Facility, Edwards, California 

Randal W. Brumbaugh 

PRC Kentron, Edwards, California 


1986 


(VI/\SA 

National Aeronautics and 
Space Administration 
Ames Research Center 
Dryden Flight Research Facility 
Edwards, California 93523 





AN ENGINEERING APPROACH TO THE USE OF EXPERT SYSTEMS 
TECHNOLOGY IN AVIONICS APPLICATIONS 

Eugene L. Duke, Victoria A. Regenie, and Marylouise 8razee 
NASA Ames Research Center 
Oryden Flight Research Facility 
Edwards, California 

Randal W. Brumbaugh 
PRC Kentron 
Edwards, California 


Abstract 

This paper presents the concept of using a 
knowledge compiler to transform the knowledge base 
and inference mechanism of an expert system into 
a conventional program. The motivation for this 
discussion is the need to accommodate real-time 
systems requirements in applications such as 
embedded avionics. The paper presents an over- 
view of expert systems and a brief comparison of 
expert systems and conventional programs. Avi- 
onics applications of expert systems are briefly 
discussed before the detailed discussions of 
applying the proposed concept to example sys- 
tems using forward- and backward-chaining. 


Introduction 

Expert systems technology offers tremendous 
potential for the next generation of avionics 
systems. The power of this technology lies both 
in its separation of domain specific knowledge 
from program control mechanisms and in the devel- 
opment methodology and development environment. 
However, as expert systems technology moves out 
of the research laboratory and into severely 
demanding applications such as avionics, new 
problems arise. While the power of expert sys- 
tems is evident in the laboratory environment, 
many of the most attractive features of this 
technology become burdensome in applications. 

It is argued in this paper that, by treating 
expert systems as development tools for more 
conventional programs, many of the problems 
emerging in applications may be solved. It is 
the thesis of this paper that an engineering 
approach to the use of expert systems technol- 
ogy in avionics application may minimize the 
need for special purpose computers. 

The concept of using an expert system as 
a development tool for a conventional program 
arose from the applications research at the 
Oryden Flight Research Facility of the NASA 
Ames Research Center (Ames-Dryden) and was 
suggested by the research at the University 
of California, Los Angeles (UCLA), under the 
direction of Professor Jacques Vidal. This 
research in real-time mechanizations of expert 
systems has influenced some of the key ideas 


presented in this paper. In particular, the 
doctoral thesis of John Helly [1] has provided 
a unique and original view of the transforma- 
tion of a knowledge base into an equivalent 
logic representation. 

At Ames-Dryden, expert systems technology 
is being applied to avionics systems on high- 
performance aircraft in two projects: the expert 

system flight status monitor for the X-29 forward- 
swept-wing aircraft [2], [3] and in the joint NASA/ 
DARPA automated wingman program. Both NASA proj- 
ects focus on the use of expert systems technology 
in real-time applications. The application areas 
In which this research is being conducted are such 
that extreme computational demands are placed on 
the host computer system. The complexity of high- 
performance aircraft place severe demands on 
expert systems technology. The following sec- 
tions present an overview of expert systems and 
a comparison of expert systems and conventional 
programs as background before proceeding with 
the main argument of the paper: expert systems 

can be converted automatically into conventional 
programs and the process from development to 
deployment retains the best features of both 
types of systems. 

It is the thesis of this paper that the 
knowledge base and inference mechanism of an 
expert system can be converted into a conventional 
program using a knowledge compiler. The concept 
of a knowledge compiler is explained using example 
forward- and backward-chaining expert systems. 

The main benefit of converting the expert system 
into a conventional program is increased execution 
speed and, hence, reduced processor requirements. 
The knowledge compilation method described in this 
paper is completely compatible with the usual 
environment available for expert systems develop- 
ment and allows the system developer to exploit 
the desirable features of expert systems while 
developing conventional programs. 

Overview of Expert Systems 

Artificial intelligence (AI) is described in 
Ref. 4: 

"...the part of computer science concerned 
with designing intelligent computer systems. 



that is, systems that exhibit the characteris- 
tics we associate with intelligence in human 
behavior...." 

AI research focuses on understanding the basic 
processes of intelligence as well as on computer- 
based methodologies for solving difficult problems 
that would otherwise require human intelligence. 
The field of AI is concerned with a wide range of 
problem classes that are associated with intel- 
ligence in humans: problem solving, reasoning, 

understanding language, learning, robotics, auto- 
matic programming, and vision. 

The research in problem solving and reasoning 
has led to the development of the subfield of 
applied AI known as expert systems in which 
general-purpose reasoning engines (inference 
mechanisms) are utilized to reason about domain 
specific knowledge in a target application area. 

An expert system is described in Ref. 5: 

"An expert system is one that has expert 
rules and avoids blind search, performs well, 
reasons by manipulating symbols, grasps funda- 
mental domain principles, and has complete weaker 
reasoning methods to fall back on when expert 
rules fail and to use in producing explanations. 

It deals with difficult problems in a complex 
domain, can take a problem description in lay 
terms and convert it to an internal representa- 
tion appropriate for processing with its expert 
rules, and it can reason about its own knowledge 
(or lack thereof), especially to reconstruct 
inference paths rationally for explanation and 
self-justification." 

This description of an expert system is more 
of a future goal than a current reality. The 
incorporation of fundamental domain principles 
into what are known as "deep" expert systems is 
at best a research topic; most expert systems have 
an extremely limited and shallow knowledge base. 
This lack of knowledge of fundamental principles 
contributes to the inability of current generation 
expert systems to reason about their knowledge in 
general and about the limitations of their knowl- 
edge in particular. However, many of the fea- 
tures listed in this description do exist in what 
might be termed the state of the art in applica- 
tion systems. 

Figure 1 shows a common (although highly 
simplified) representation of the basic expert 
systems architecture. In this representation, 
the main structural features of an expert system 
are illustrated: knowledge acquisition facility, 

knowledge base, inference mechanism, and input- 
output system. The knowledge acquisition facility 
is the main interface between the expert system 
and the expert. This facility provides a mech- 
anism for developing a knowledge base. The knowl- 
edge base consists of domain specific knowledge, 
generally in the form of conditional (if-then) 
rules. The inference mechanism reasons about 
specific facts using this knowledge base. In 
this simplified representation of an expert 


system, the inference mechanism would also pro- 
vide explanations of conclusions reached and rules 
used to reach those conclusions. The knowledge 
acquisition facility, inference mechanism, and 
input-output system are part of the expert system 
program. After the specific facts that are to be 
reasoned about are provided, the knowledge base is 
treated as a data source that is used to direct 
the inference process. 

Perhaps the most significant feature of cur- 
rent expert systems is the use of knowledge in 
the form of expert rules that represent domain 
principles. Encoding the knowledge and problem 
solving techniques of a domain expert into rules 
provides the real power of expert systems. These 
rules are used by an inference mechanism both to 
reason about specific facts in a given situation 
and to provide explanations of the deductions of 
the expert system to its user. Figure 2 shows 
what might be typical rules used in avionics 
applications. These rules might be used in 
flight control systems, guidance systems, and 
even more powerful integrated systems such as 
those being developed for the pilot's associate 
program. Figure 3 shows how these same rules 
would be coded in a higher order language (in 
this case, FORTRAN). As can be seen by comparing 
Figs. 2 and 3, the representation of knowledge is 
much clearer and more easily verified in the rules 
(Fig. 2) than in the FORTRAN code (Fig. 3). 

Expert Systems and Conventional Programs 

When comparing an expert system with a con- 
ventional program, differences in knowledge rep- 
resentation, control structure, and operational 
processes are most obvious. Expert systems use 
symbolic representations of knowledge and symbolic 
inference; conventional programs use numeric and 
logical representations. An expert system might 
be said to execute a compilation of knowledge 
while a conventional program might be character- 
ized as a compilation of procedures. The struc- 
ture of an expert system in which the knowledge 
base and inference mechanism are separated, 
differs from a conventional program in which 
the knowledge base and inference mechanism are 
essentially combined in the program code. The 
main operational differences arise from the abil- 
ity of an expert system to offer explanations of 
its inference process and to have that inference 
process modified by the addition, deletion, or 
modification of rules. In a conventional pro- 
gram, explanation features are lacking and the 
modification of the reasoning process involves 
rewriting the code. Obviously, the features that 
characterize an expert system are intertwined and 
cannot be separated. 

In addition to the representational, struc- 
tural, and operational differences, expert sys- 
tems also differ from conventional programs in 
their development. In a conventional program, 
the possible lines of reasoning must be mapped 
out ahead of time and then rigidly encoded into 
the program structure. In an expert system. 
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because the lines of reasoning are embodied in 
the knowledge base, the system can be developed 
incrementally. The environments in which these 
two types of programs are developed also differ 
radically. Conventional programs are most often 
developed in the target programming language with 
few support tools beyond an editor and, perhaps, 
a debugger. The environment for expert systems 
development is fundamentally far richer than 
that for conventional programs. Figure 4 shows 
the components of an expert system and illus- 
trates the benefit of using an expert systems 
shell in the development process. Expert sys- 
tems shells are available with inference mech- 
anisms, a knowledge acquisition facility, and 
explanation capabilities already developed and 
in place. The knowledge engineer need only com- 
pile the domain specific knowledge of an expert 
and enter it into the shell. By using an expert 
systems shell, an expert system can be developed 
rapidly. Entering only a few key rules into a 
shell allows a system to be prototyped quickly 
and allows early feasibility demonstration. 

It should be noted at this point that, when 
discussing expert systems, some distinction is 
occasionally made between development and deliv- 
ery systems. The distinction is not entirely 
clear. A delivery system must at least have a 
knowledge base, an inference mechanism, and an 
explanation facility. A delivery system is 
probably not one with the capability for knowl- 
edge base modification, while the capability 
for knowledge base modification is an essential 
feature of a development system. This distinc- 
tion between development and delivery systems 
will be avoided in this discussion; it will be 
assumed that all expert systems are capable of 
knowledge base modification. 

Avionics Applications of Expert Systems 

The main interest in using expert systems 
technology in avionics arises from the complex- 
ity of the missions to be performed and the 
demanding environments in which these missions 
must be performed. Consideration of these fac- 
tors have forced requirements for increasingly 
more complex systems. The emerging generation 
of tactical vehicles (fighters and attack heli- 
copters) are near the limit of what can be accom- 
plished using a single pilot and conventional 
technology. Additionally, these systems require 
the pilot to perform at a level that is near (if 
not beyond) the limits of human performance. 

When all systems are operational, the basic tasks 
facing the pilot are data interpretation and sub- 
systems integration. When problems arise in the 
avionics subsystems of these emerging systems, the 
pilot may be unable to cope with the situation 
because of the complexity of the subsystems and 
their interactions within the vehicle system as a 
whole. Expert systems technology offers the pos- 
sibility of solving these problems by providing 
the pilot with useful knowledge and assistance. 

The main interest in using expert systems tech- 
nology in avionics applications is that it may be 


the only means of providing the next level of sys- 
tems integration. 

Many avionics applications of expert sys- 
tems technology are possible. These applications 
include examples of most of the class of expert 
systems problems described in Ref. 5: interpre- 

tation, prediction, diagnosis, planning, moni- 
toring, debugging, repair, and control. Most of 
these applications will be embedded in other 
systems or will serve to integrate subsystems. 
Sensor fusion is an excellent example of inter- 
pretation in which multiple sensors provide 
diverse pieces of data that must be integrated 
into a coherent picture of the world outside the 
aircraft. The prediction problem is exemplified 
by tactics prediction in which the future tac- 
tics of an opponent would be predicted from past 
performance. Diagnosis could be applied to the 
isolation of a failure within a flight control 
system. Planning systems have obvious and 
immediate applications in route planning and 
target allocation problems. Monitoring systems 
could be used to assess the health and status of 
any of the various subsystems within the aircraft 
or of the effectiveness of the aircraft as a 
weapons system. Expert systems that diagnose, 
debug, or repair could be employed to provide the 
expertise needed in a reconfigurable control sys- 
tem. In this application, problems in a flight 
control system could be corrected by reconfig- 
uration (repair) after specific malfunctions 
determined from sensor and aircraft behavior 
(diagnosis) had been analyzed and corrective 
measures had been identified (debugging). 

Finally, control expert systems could be used 
to integrate the subfunctions of an avionics 
system at the mission level. Obviously, this 
list of applications is not exhaustive, and the 
problem areas are not disjoint. However, this 
list of applications provides some insights 
into the problems associated with the use of 
expert systems in avionics applications. 

All avionics software must execute in a real- 
time environment in which the timeframe is deter- 
mined by the application; the slowest of these 
applications are those that interface with the 
pilot or involve long-term planning, and the 
fastest are those that involve flight control 
systems or weapon sensors. The need for real- 
time operation makes speed of execution a criti- 
cal consideration in any examination of the 
tradeoffs between two competing pieces of soft- 
ware. Even with development of newer and more 
powerful avionics computers, software efficiency 
will continue to be an issue. More capable com- 
puters will merely result in greater demands; more 
computational power will simply result in greater 
expectations. Avionics computers will continue to 
be utilized to the maximum that can be obtained 
from them. The problems of real-time programming 
will continue to be a concern, and it is here 
that expert systems become burdensome. 

One of the first rules of real-time program- 
ming is to develop an efficient code. As illus- 
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trated in the Transforming Expert Systems Into 
Conventional Programs section, expert systems 
are iterative in nature and the time required to 
converge to an answer varies with the situation 
being analyzed. While expert systems are more 
efficiently developed than conventional programs, 
expert systems are necessarily more inefficient 
in execution. Further, this inefficiency has 
nothing to do with the speed at which a computer 
executes LISP, FORTRAN, or any other computer 
language. The inefficiency of expert systems is 
inherent in the separation of the knowledge base 
and the control mechanism and in the iterative 
nature of the control process. Because the inef- 
ficiency of an expert system increases rapidly as 
the size of the knowledge base increases, some 
consideration has been given to dividing knowledge 
bases into smaller partitions. However, this 
latter approach does not eliminate the problem of 
inefficiency; it merely alleviates it. 

Although some of the previously discussed 
applications require a direct interface with the 
pilot, not all do. In fact, many of these appli- 
cations such as sensor fusion and flight control 
system reconfiguration will be imbedded in other 
systems and isolated from the pilot. The value 
of the high-level user interface characteristic 
of expert systems is thus unnecessary in many 
avionics applications. However, even if it is 
assumed that an explanation feature is required 
of the man-machine interface, the capability of 
knowledge base or program control modification 
is almost certainly not a requirement of an 
avionics system, whether it is an expert system 
or a conventional system. In fact, if any pro- 
gram control modifications are to be permitted 
in avionics systems, these will almost certainly 
be known, well-defined options that are built 
into the system. 

The least consideration in avionics systems 
should be abandoning standard systems qualifica- 
tion procedures for the lure of exotic technology 
that allows a pilot to modify a system in real 
time. The requirement for an explanation in an 
avionics application is almost certainly weaker 
than the requirement for an explanation in a devel- 
opment system. At most, it might be expected that 
a first-level explanation would be required. A 
first-level explanation is an explanation of the 
last rule used to reach a conclusion. This type 
of explanation is in contrast to the sort of 
detailed backward justification available in 
some current expert systems. 


To illustrate how expert systems can be 
mapped into conventional programs, two examples 
of production rule systems are given: one with 

a forward-chaining inference mechanism and one 
with a backward-chaining inference mechanism. 

These examples, while extremely simple, will 
facilitate an understanding of the proposed 
approach. Further, these examples will serve 
to illustrate the tradeoffs involved in convert- 
ing an expert system into a conventional program. 
The first two subsections provide a brief intro- 
duction to the inference mechanism, present a 
sample set of rules, and then show the equivalent 
FORTRAN representation. In the final subsection, 
expert systems and their transformations into con- 
ventional programs are discussed. 


In the following examples, FORTRAN is used to 
illustrate the use of a higher order language. 
FORTRAN was chosen for two reasons: because of 

the authors' familiarity with the language and 
because FORTRAN is the primary computer language 
used in conventional scientific and engineering 
applications. This language is also supported on 
most machines by fast, efficient optimizing com- 
pilers. The perception that FORTRAN is probably 
unsuitable for AI applications also influenced the 
decision. Although at least one expert systems 
shell has been implemented in FORTRAN (the TIMM 
expert systems generation tool by General Research 
Corporation), FORTRAN is generally considered the 
antithesis of a suitable AI language. All examples 
of FORTRAN code presented in this paper could as 
easily have been shown in LISP, Ada, C, or any 
other higher order language. 

Forward-Chaining Example 

Forward-chaining is often referred to as 
"data-driven" inference because the rules are 
applied to the established facts to reach whatever 
conclusions are consistent with the given facts 
and the rules. Forward-chaining inference stops 
when a pass (iteration or cycle) through the rules 
yields no new facts and the inference process is 
complete. A set of example rules in which clauses 
have been replaced by symbols is as follows: 


Rule 

number 


Rule 


1 If c or f then d 

2 If d then e 

3 If b and a then c 


Transforming Expert Systems 
Into Conventional Programs 

This section describes a mechanism for con- 
verting expert systems into conventional programs. 
The requirements outlined in the previous section 
are taken as the requirements for the conversion 
process described here. While the examples that 
follow are only for simple forward- and backward- 
chaining inference mechanisms, these inference 
mechanisms can be and are being utilized for a 
wide variety of applications in avionics. 


4 If a then b 

Figure 5 shows the results of applying these 
rules with a forward-chaining inference mech- 
anism in a situation in which only the fact a 
is established initially. In this simple example, 
five inference cycles are required before the 
stopping rule is satisfied. 

Figure 6 shows three FORTRAN representations 
of a logically equivalent reasoning process. The 
three examples of FORTRAN correspond to steps in 
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the conversion process from the expert system to 
conventional code. To achieve the direct repre- 
sentation, all clauses would be assigned a vari- 
able name and the rules would be translated 
directly into code. In the second step of the 
conversion process, all clauses that are only 
used as antecedents are taken as the basic in- 
put symbols (primitives), and then each rule is 
expanded until it is expressed entirely in terms 
of these primitives. (Here, to simplify the 
discussion, these primitives are assumed to rep- 
resent the input data to the expert system.) The 
final simplified FORTRAN code is established by 
applying standard methods for reducing Boolean 
expressions, such as the Quine-McCluskey minimi- 
zation method [7]. A set of rules to be used by 
a forward-chaining inference mechanism is thus 
transformed into a single-pass, conventional 
set of higher order language expressions. 


Backward-Chaining Example 


Backward-chaining inference is often referred 
to as "goal -driven" inference because the infer- 
ence mechanism begins with an ordered list of 
goals (hypotheses) and uses the knowledge base to 
attempt to find a set of rules that allows these 
hypotheses to be concluded. If the first hypothe- 
sis cannot be satisfied, using the knowledge base 
and established facts, the second hypothesis is 
attempted. This process continues until a hypoth- 
esis can be asserted or until the list of hypoth- 
eses is exhausted. A list of rules and an ordered 
set of hypotheses are given below. 


Rule 

number 


Rule 


Hypothesis 


1 

2 

3 

4 

5 

6 


If a and b and c then d 
If e and f then a 
If g or h then b 
If i and j then c 
If c and a then b 
If e and i then g 


d 

b 

a 


To illustrate backward-chaining, the facts e and 
f are established initially. Because the hypoth- 
eses are ordered, the backward-chaining mechanism 
first attempts to conclude d. This is done by 
finding a rule with d as the consequent — in this 
case, rule 1 above. The backward-chaining mech- 
anism then compares the established facts and 
attempts to satisfy the rule antecedents from 
those facts. If a, b, and c are not established 
facts (and, in this case, they are not), the 
backward-chaining mechanism must repeat the 
process of finding rules with each of the sub- 
hypotheses as consequents. In doing so, it must 
test those rule antecedents against the estab- 
lished facts and continue until either the list 
of rules has been exhausted or all antecedents 
for some hypothesis can be satisfied. Attempting 
to assert d results in the search-tree shown in 
Fig. 7. In this example, the hypothesis d would 
be abandoned and the backward-chaining mechanism 
would test to see if the next hypothesis b could 


be asserted. Given the rules and established 
facts in this example, a can be asserted using 
rule 2. The backward-chaining mechanism would 
assert a, after trying to assert d and b in turn, 
and stop. 

Figure 8 shows how the rules and hypotheses 
discussed above could be represented as FORTRAN 
code. As in the forward-chaining example, the 
conversion from rules to FORTRAN code is a three- 
step process. To achieve the direct represen- 
tation, all clauses would be assigned variable 
names and the hypotheses would be translated 
directly into the code. The second step of the 
transformation process once again requires that 
the clauses that are used only as antecedents be 
identified as primitives (and that these primi- 
tives are assumed to represent input data). The 
representations of the ordered hypotheses are 
expressed in terms of the primitives. The final 
step of the transformation again requires the 
application of a method for reducing Boolean 
expressions and results in the FORTRAN code pre- 
sented as the "representation after substitution 
and reduction" in Fig. 8. The difference between 
this single-pass code and the backward-chaining 
example is that all hypotheses that can be satis- 
fied will be satisfied. To provide an equivalent 
mechanism to the backward-chaining example, a test 
and return must be inserted after each represen- 
tation of a hypothesis (Fig. 8) and a variable 
(NULHYP) created to indicate when no hypothesis 
could be satisfied. 

Comparison of Example Expert Systems and 
Their Conventional Code Representations 

In the examples of forward- and backward- 
chaining, the conversion of rules into a conven- 
tional code results in a logically equivalent 
representation of the knowledge base and inference 
mechanism. However, the flexibility of the expert 
systems has been converted into the rigidity of a 
conventional code. Yet if this conversion is 
automatic, nothing has been lost. Another step 
in the development process has been inserted (the 
conversion process). However, this is a minor 
inconvenience when considered in the context of 
a program that would execute faster and could 
easily be hosted on any of a number of numeric 
processors. Obviously, the conventional code is 
less readable and self -documenting than the rules 
would be for an expert system. Nevertheless, the 
readability and code documentation are critical 
only if the code must be maintained and modified 
by humans. In the processes described above, mod- 
ification and maintenance of the knowledge base 
would occur within the context of the expert sys- 
tems development environment. When the knowledge 
base is modified, a new piece of conventional 
source code could be generated and the old code 
could be discarded. This process would then be 
similar to the use of a standard compiler. In 
fact, a knowledge compiler is exactly what is 
being proposed in this paper. 

It is important to understand what would be 
lost in the transformation of expert systems to 
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conventional code in the examples given. While 
the conventional code is logically equivalent to 
the knowledge base of the example expert systems, 
no provision is made in these examples of a con- 
ventional code for an explanation feature. At 
the user interface, no provision is made for rule 
modification or even for the display of rules. As 
discussed in the Avionics Applications of Expert 
Systems section, the provision for knowledge base 
maintenance in the application system is neither 
required nor desirable, but some form of explana- 
tion feature is, at times, desirable. 

A first-level explanation can easily be gen- 
erated using a subroutine (procedure) in addition 
to the subroutine that performs the logical infer- 
ence. This subroutine would, in essence, contain 
formatted representations of the knowledge base 
rules. Returning to the example rules in Figs. 2 
and 3 and assuming that all rules would be used in 
situations requiring explanation, the subroutine 
shown in Fig. 9 could be generated from the rules 
to provide the needed explanation. In the example 
shown in Fig. 9, the explanation in the format 
statement would be displayed to the use.r (pilot) 
whenever the logical variable (Cl, C2, C3, C4, or 
C5) corresponding to the rule consequent of the 
formatted rule was true. That is, if the equiva- 
lent of the first rule in Fig. 2 could have been 
used to conclude that the "longitudinal rate 
damping mode is inoperative" and Cl in Fig. 3 
would have been true, then the rule encoded in 
format statement 101 in Fig. 9 would be displayed 
as an explanation. 

Concluding Remarks 

A brief introduction to expert systems is pre- 
sented in this paper. Expert systems are compared 
to conventional programs and then discussed within 
the context of avionics applications. After des- 
cribing the need for expert systems in avionics 
applications, the problems posed by this technology 
are discussed. Two example inference mechanisms 
(forward- and backward-chaining) are described and 
used to exemplify the proposed technique of con- 
verting expert systems knowledge bases into con- 
ventional programs. 

This paper presents the concept of using a 
knowledge compiler to convert the knowledge base 
developed for an expert system into a conventional 
program. This concept allows the most desirable 
features of expert systems to be retained and also 
provides a means for producing fast, efficient 
code capable of execution on any processor. While 
discussed within the context of avionics applica- 
tions, this concept has utility in other applica- 
tions where execution speed is not the primary 
consideration but where the options available for 
target machines are limited. 


While the expert systems examples presented 
in this paper are extremely simplified, they are 
representative of two powerful inference mech- 
anisms that are applicable to a wide range of 
problems. By demonstrating that the knowledge 
bases and inference mechanisms used in these 
example expert systems can be converted into 
conventional programs, it has been shown how 
some of the problems of using expert systems 
in avionics applications may be minimized. 

In fact, the proposed approach need not be 
limited to avionics applications. For any sys- 
tem that can be converted using this technique, 
the advantages are significant. While the use 
of symbolic processors in research and develop- 
ment laboratories has many benefits, the costs 
associated with these single-user, special- 
purpose systems may make them unsuitable for 
target applications. The technique described 
in this paper provides a means for converting 
expert systems from symbolic processors to 
numeric processors. 
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Expert 

User 

Cl 

= (A1 

AND 

A2 

t 

t 

C2 

C3 

= (A3 

.OR. 

OR 

A4 

A A 

Knowledge acquisition 

Input -output 

C4 

— 

= (A5 

AND. 

A6 

facility 

system 

C5 

= (A7 

AND 

A8 


Advice, 

explanations 


Specific 

facts 


where 

A1 


Knowledge base 



Inference mechanism 


Knowledge engineer ‘ 

Fig. 1. Basic expert systems architecture. 


the primary pitch rate gyro has failed 
and the backup pitch rate gyro has failed 

i 

the longitudinal rate damping mode is inoperative 


the pilot has selected the air-to-air gun mode 
or the guidance system has selected the air-to-air gun 
mode 

i 

the flight control system is in the fuselage pointing 
mode 

and the air-to-air gun mode indicator is on 


the mission is interception 
and the fuel is not sufficient for a minimum-time 
interception with maximum thrust 
l 

use the minimum-time to a cruise energy algorithm 


the ground-based threat data base has been updated 
and the risk associated with the new situation is 
unacceptably high 

i 

the route should be replanned 


Fig. 2. Example rules for avionics applications . 



= the primary pitch rate gyro has failed 
= the backup pitch rate gyro has failed 
= the pilot has selected the air-to-air gun mode 
= the guidance system has selected the air-to-air 
gun mode 

= the mission is interception 
= the fuel is not sufficient for a minimum-time 
interception with maximum thrust 
= the ground-based threat data base has been 
updated 

= the risk associated with the new situation 
is unacceptably high 
= the longitudinal rate damping mode is 
Inoperative 

3 the flight control system is in the fuselage 
pointing mode 

= the air-to-air gun mode indicator is on 
= use the minimum-time to a cruise energy 
algorithm 

3 the route should be replanned 


Fig. 3. FORTRAN representation of example rules 
for avionics applications . 



'Consultation 

manager 


Knowledge \ 
base editor 
and debugger 


Knowledge \ 

Explanation I base Inference ' 

facility | management mechanism 

facilities 


Expert 

system 

shell 


Fig. 4. Components of an expert system. 
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Direct representation: 

D =((A .AND B) .AND. C) 

B =((G .OR. H) .OR. (C AND. A)) 

A = (E .AND. F) 

Representation after substitution: 

D =(((E AND F) .AND «E .OR I) .OR. H» .AND (I AND. J)) 

B =(((E .AND. I ) .OR. H) OR. ((I .AND. J) .AND. (E .AND. F))) 
A = (E .AND. F) 

Representation after substitution and reduction- 
D =(((E .AND. F) .AND. I) .AND. J) 

IF D RETURN 
B = ((E .AND. I) OR H) 

IF B RETURN 
A = (E .AND. F) 

IF A RETURN 
NULHYP=. TRUE. 


Fig. 8. FORTRAN representation of backward-chaining 
example. 


SUBROUTINE EXPLAN 


COMMON /CFACTS/ Cl ,C2 ,C3 ,C4 ,C5 


IF 

IF 

IF 

IF 

IF 

IF 


(.NOT EXPLIN) RETURN 


(Cl ) 
(C2 ) 
<C3 ) 
<C4 ) 
(C5 ) 


WRITE 

WRITE 

WRITE 

WRITE 

WRITE 


RETURN 


(*. 101 ) 

(*, 102 ) 

(*.103) 

(*,104) 

(*,105) 


101 FORMAT( “ The longitudinal rate damping mode Is”, 

“ Inoperative”, /, 

“ because the primary pitch rate gyro has failed”,/, 

“ and the backup pitch rate gyro has failed.”) 

102 FORMAT ( “ The flight control system Is In the fuselage”, 

“ pointing mode”,/, 

“ because either the pilot has selected the”, 

“ air-to-air gun mode”,/, 

, “ or the guidance system has selected the”, 

“ air-to-air gun mode.”) 

103 FORMAT( “ The alr-to-alr gun mode Indicator Is on”,/, 

“ because either the pilot has selected the”, 

“ air-to-air gun mode”,/, 

“ or the guidance system has selected the”, 

“ air-to-air gun mode.”) 

104 FORMAT(“ Use the minimum-time to a cruise energy”, 

“ algorithm”,/, 

“ because the mission is Interception”,/, 

“ and the fuel Is not sufficient for a”, 

“ minimum-time Interception with maximum thrust.”) 

105 FORMAT/ “ The route should be replanned”,/, 

“ because the ground-based threat data base has”, 

“ been updated”,/, 

“ and the risk associated with the new situations”, 

" Is unacceptably high.”) 

END 


Fig. 9. FORTRAN subroutine to provide first-level 
explanation. 
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